home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / iesg / 92_12_21 < prev    next >
Text File  |  1993-02-04  |  13KB  |  350 lines
  1.  
  2.       
  3.                     IETF STEERING GROUP (IESG)
  4.  
  5.                   REPORT FROM THE IETF MEETING
  6.  
  7.                        December 21th, 1992
  8.  
  9.          Reported by:  Greg Vaudreuil, IESG Secretary
  10.  
  11. This report contains IESG meeting notes, positions and action items.
  12.  
  13. These minutes were compiled by the IETF Secretariat which is supported
  14. by the National Science Foundation under Grant No. NCR 8820945.
  15.  
  16. For more information please contact the IESG Secretary.
  17.  
  18.  
  19. ATTENDEES
  20. ---------
  21.  
  22.     Almquist, Philip / Consultant
  23.     Crocker, Dave / TBO
  24.     Crocker, Steve / TIS
  25.     Coya, Steve / CNRI
  26.     Davin, Chuck / Bellcore
  27.     Gross, Philip / ANS
  28.     Hinden, Robert / SUN
  29.     Hobby, Russ / UC-DAVIS
  30.     Huizer, Erik / SURFnet
  31.     Stockman, Bernard / SUNET/NORDUnet
  32.     Vaudreuil, Greg / CNRI
  33.  
  34. Regrets
  35.     Borman, David / Cray Research
  36.     Knowles, Stev / FTP Software
  37.     Reynolds, Joyce / ISI
  38.     Piscitello, Dave/ Bellcore
  39.  
  40.  
  41. AGENDA 
  42. ------
  43.  
  44. 1) Administrivia 
  45.  
  46.  o Bash the Agenda
  47.  
  48.  o Review of Minutes
  49.    - December 7th
  50.    - December 14th
  51.  
  52. 2) IESG Nominations 
  53.  o Selection of additional members to stand re-nomination
  54.  o Selection of IESG non-voting members of nomination committee.
  55.  
  56. 3) Technical Management 
  57.  o Status of Road feedback 
  58.  
  59. 3) Protocol Actions 
  60.  o IESG approval needed
  61.    - FTP/FTAM  
  62.    - Privacy Enhanced Mail
  63.  
  64.  o IESG action needed
  65.    - MTU Discovery
  66.    - PPP MIBS    
  67.    - Sun NFS/RPC 
  68.  
  69.  o Working Group Discuss
  70.    - DHC 
  71.    - SMTPext 
  72.    - Header Compression
  73.    - Network Time Protocol
  74.  
  75. 4) Working Group Actions
  76.  o IP Security (ipsec)
  77.  o Simple IP (sip)
  78.  
  79. 5) Technical Management  
  80.  o 48bit CRC patent Issue
  81.  o Review of Action Items
  82.  
  83.  
  84. MINUTES
  85. -------
  86.  
  87. 1) Administrivia
  88.  
  89.    The minutes of the December 7th and 14th Teleconferences were
  90.    approved.
  91.  
  92. 2) IESG Nominations
  93.  
  94.    There are 14 members currently on the IESG.  This number will remain
  95.    constant through the next IESG realignment. The Internet,
  96.    Applications, and Operations Areas each have two IESG members.  The
  97.    IESG agreed that only one of the two directors should stand for
  98.    re-nomination at one time. The IESG established the following
  99.    rotation for IESG member selection.
  100.  
  101.    Position         This year         Next year   
  102.  
  103.    Chair            Phill Gross 
  104.    Standards        Dave Crocker        --
  105.    Applications     Russ Hobby        Erik Huizer
  106.    Internet         Stev Knowles      Dave Piscitello 
  107.                     Phil Almquist
  108.    Management         --              Chuck Davin
  109.    Operations       Phill Gross(*)    Bernard Stockman
  110.    Routing            --              Bob Hinden
  111.    Security           --              Steve Crocker
  112.    Service Apps     empty (*)           --
  113.    Transport        Dave Borman(*)      --
  114.    User Services      --              Joyce Reynolds
  115.  
  116.    (*) Open positions
  117.  
  118.    Three IESG members intend to resign their position at the end of
  119.    their terms, Philip Almquist, and Dave Borman.  Phill Gross will not
  120.    seek re-selection for the Operational Requirements Area but will
  121.    seek re-selection as chairman. Dave Crocker, Steve Knowles, and Russ
  122.    Hobby presented themselves as candidates to continue in their
  123.    respective positions.
  124.  
  125.    The IESG choose Erik Huizer as the non-voting IESG liaison person to
  126.    the nomination committee.
  127.  
  128. ACTION: Gross -- Communicate to the IETF the list of IESG positions to
  129. be filled during the next selection process and the names of the IESG
  130. members who wish to be considered for continuation in their present
  131. positions.
  132.  
  133.    The question was raised of whether the IESG chairman was
  134.    automatically a member of the IAB.  This and other questions about
  135.    liaison between the IAB and IESG were distilled into a strawman
  136.    POSITION.
  137.  
  138.    STRAWMAN: The IESG chair shall be one of two IESG members serving as
  139.    liaison members of the IAB.  Two IAB members should be designated to
  140.    act as liaison members of the IESG for the purpose of offering
  141.    architectural input to IESG deliberations.
  142.  
  143. ACTION: Gross -- Communicate the proposed liaison arrangements with the
  144. IAB and work towards common understanding of the mechanisms for
  145. communication between the IAB and IESG.
  146.  
  147. 3) Technical Management Issues
  148.  
  149.  o Feedback to the IETF on ROAD Proposals
  150.  
  151.    Stev Knowles wrote a draft note to the IETF which argues the case
  152.    for an IETF selection of a single next IP version.  This note was
  153.    created to solicit community consensus on the concept of a single
  154.    solution before making the difficult decision to pick one solution.
  155.    The IESG discussed this approach and did not reach any firm
  156.    conclusions.  Discussion will be continued on the mailing list.
  157.  
  158.  o 48 Bit CRC Patent Issue
  159.  
  160.    The IESG has been asked by the PPP Extensions Working Group for
  161.    guidance on the acceptance of a proposal to the Working Group to use
  162.    a particular CRC algorithm.  The IESG and IAB had previously
  163.    discussed this issue and agreed that proprietary technology can be
  164.    use in Internet Standards provided it is made available on a
  165.    non-discriminatory basis for a reasonable fee. The Working Group is
  166.    free to reject any patented proposal when other usable alternatives
  167.    are available.
  168.  
  169. ACTION: Vaudreuil Communicate this understanding of the use of patented
  170. technology in Internet Protocols to the PPP Extensions Working Group.
  171.  
  172.  o Protocol Approval Process
  173.  
  174.    The IESG further defined its procedures for approving protocols. 
  175.  
  176. POSITION: A protocol will pass the IESG if nine members vote
  177. affirmatively.  This balloting will be done by email and during
  178. regularly scheduled teleconferences. If there is a single "discuss"
  179. vote, or an inadequate number of "yes" votes, a teleconference
  180. discussion will be scheduled.
  181.  
  182. 4) Protocol Actions
  183.  
  184.  o FTP/FTAM Gateway Specification
  185.  
  186.    The IESG discussed the FTP/FTAM Gateway and the one question raised
  187.    was of constituency.  The IESG was satisfied that the initial
  188.    implementation experience and emerging FTAM services demonstrated
  189.    a need for a common protocol.
  190.  
  191. ACTION: Vaudreuil -- Send out the Protocol Action for FTP/FTAM to
  192. Proposed Standard.
  193.  
  194.  o Privacy Enhanced Mail
  195.  
  196.    Several issues were raised with respect to the reliance on patented
  197.    technology in the PEM protocol.  While these issues have been
  198.    addressed in the course of deliberating on PEM, there was a desire
  199.    to have their results of these discussions documented.
  200.  
  201.    PEM relies upon patented technology, RSA public key cryptography.
  202.    The IAB deliberated at length about the licensing requirements for
  203.    patented technology and the IESG would like to review these
  204.    deliberations.  A letter explaining the licensing was submitted by
  205.    RSA to the IAB. The IESG has not seen this letter and wants to
  206.    insure the terms are reasonable and that the letter gets published
  207.    as an Informational RFC.
  208.  
  209. ACTION: Coya -- Get a copy of the letter sent by RSA to the IAB on the
  210. license terms for RSA technology in PEM from Braden and make it
  211. available to the IESG for review.
  212.  
  213.   Free software based on the PEM specifications may be useful without
  214.   any license.  A key must be attained at some cost to sign, encrypt,
  215.   and decrypt messages, but authenticated messages can be verified
  216.   without any licensing.
  217.  
  218. ACTION: SCrocker -- Send to the IESG a summary of the functionality of
  219. PEM and the requirements in terms of licensing for each of the PEM
  220. functions, Encryption, Decryption, Signing, and Authenticating.
  221.  
  222.    The PEM protocol specifies one suite of algorithms, viz DES for
  223.    symmetric key encryption, RSA for asymmetric key signature and
  224.    key exchange, and MD2 and MD5 for cryptographic hash.  The
  225.    specification leaves the door open to several additional suites.
  226.    The IESG questioned this approach because the sender and the
  227.    receiver must use the same suite for interoperability to be
  228.    attained.  Steve Crocker addressed the question to the IESG's
  229.    satisfaction by noting that multiple suites are likely to occur
  230.    because the U.S. Government is pushing for the use of the Digital
  231.    Signature Algorithm (DSA) and Secure Hash Algorithm (SHA) instead
  232.    of RSA and MD5, and that export laws prohibit the general export
  233.    of systems using DES for encryption but permit the general export
  234.    of systems using weaker encryption algorithms such as RC4 with
  235.    keys limited to 40 bits.  These complications are unfortunate,
  236.    but this protocol does not add any additional complexity to the
  237.    situation.
  238.  
  239.   PEM originated in a closed IRTF Research Group, the Privacy and
  240.   Security Research Group.  An IETF Working Group was chartered to
  241.   review the initial work of the PSRG subject to the open ietf process.
  242.   This review resulted in significant changes to the specification.
  243.  
  244.  o Point to Point Protocol MIBs
  245.  
  246.    Several MIBS were submitted to the IESG for consideration as
  247.    Proposed Standards.  These have not been reviewed by the Network
  248.    Management Directorate and were referred to them.
  249.  
  250. ACTION: Davin -- Begin a review of the PPP mibs in the Network
  251. Management Directorate.
  252.  
  253.  o SUN NFS/RPC
  254.  
  255.    The IESG previously approved moving these protocols to Informational
  256.    status.  Since that time, however, SUN Microsystems has initiated
  257.    discussion with the IESG to re-enter these protocols into the
  258.    standards track.  The IESG decided to hold the movement of these
  259.    protocols to Informational until the situation becomes more clear.
  260.  
  261. ACTION: Vaudreuil -- Do not sent the SUN NFS/RPC protocol action moving
  262. these protocols to Informational.  Schedule a discussion on these
  263. protocols for January 21st if no progress is made.
  264.  
  265.  o SMTP Extensions
  266.  
  267.    The SMTP Extensions for 8 bit transport have been submitted to the
  268.    IESG for re-consideration as a Proposed Standard.  The document
  269.    originally submitted to the IESG has been split into several smaller
  270.    documents with significant technical changes.
  271.  
  272. ACTION: Vaudreuil - Issue a Last Call for the SMTP Extensions
  273. Documents.
  274.  
  275.  o Network Time Protocol
  276.  
  277.    There was nothing to report on the status of the NTP Version 3
  278.    review.
  279.  
  280. 5) Working Group Actions
  281.  
  282.  o IP Security
  283.  
  284.    The IP Security charter was accepted in principle.  In the absence
  285.    of a Security architecture, the IESG requests a statement in the
  286.    charter about how this relates to other IP security efforts in the
  287.    IETF including Common Authentication Technology, US Department of
  288.    Defense IP Security Option and the Commercial IP Security Option.
  289.    After the changes are made the IESG will reconsider the Working
  290.    Group proposal.
  291.  
  292. ACTION: SCrocker - With the Working Group chairs, revise the IP
  293. Security charter to address the relationship with current work Add a
  294. line to the charter addressing how this relates to other working
  295. groups. 
  296.  
  297. o Simple IP Protocol
  298.  
  299.   The IESG reviewed the SIP charter.  The milestones appear aggressive
  300.   and some concern was expressed that the December delivery dates were
  301.   not realistic for implementations.
  302.  
  303. ACTION: Vaudreuil - Contact the chairs of the SIP Working Group and
  304. confirm the milestones listed in the charter.
  305.  
  306.  
  307. Appendix -- Action Items Taken
  308. --------
  309.  
  310. ACTION: Gross -- Communicate to the IETF the list of IESG positions to
  311. be filled during the next selection process and the names of the IESG
  312. members who wish to be considered for continuation in their present
  313. positions.
  314.  
  315. ACTION: Gross -- Communicate the proposed liaison arrangements with the
  316. IAB and work towards common understanding of the mechanisms for
  317. communication between the IAB and IESG.
  318.  
  319. ACTION: Vaudreuil Communicate this understanding of the use of patented
  320. technology in Internet Protocols to the PPP Extensions Working Group.
  321.  
  322. ACTION: Vaudreuil -- Send out the Protocol Action for FTP/FTAM to
  323. Proposed Standard.
  324.  
  325. ACTION: Coya -- Get a copy of the letter sent by RSA to the IAB on the
  326. licence terms for RSA technology in PEM from Braden and make it
  327. available to the IESG for review.
  328.  
  329. ACTION: SCrocker -- Send to the IESG a summary of the functionality of
  330. PEM and the requirements in terms of licensing for each of the PEM
  331. functions, Encryption, Decryption, Signing, and Authenticating.
  332.  
  333. ACTION: Davin -- Begin a review of the PPP mibs in the Network
  334. Management Directorate.
  335.  
  336. ACTION: Vaudreuil -- Do not sent the SUN NFS/RPC protocol action moving
  337. these protocols to Informational.  Schedule a discussion on these
  338. protocols for January 21st if no progress is made.
  339.  
  340. ACTION: Vaudreuil - Issue a Last Call for the SMTP Extensions
  341. Documents.
  342.  
  343. ACTION: SCrocker - With the Working Group chairs, revise the IP
  344. Security charter to address the relationship with current work Add a
  345. line to the charter addressing how this relates to other working
  346. groups.
  347.  
  348. ACTION: Vaudreuil - Contact the chairs of the SIP Working Group and
  349. confirm the milestones listed in the charter.
  350.